install: Add --copy-etc
#267
Conversation
cgwalters
force-pushed
the
install-inject-etc
branch
from
19d3890
to
310a6fa
Compare
|
@cgwalters: The following test failed, say
Full PR test history. Your PR dashboard. Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here. |
cgwalters
force-pushed
the
install-inject-etc
branch
from
310a6fa
to
5e9e335
Compare
|
(OK yeah, need to wean this project off of FCOS for testing...gets into the messy topic of what other framework) |
| } | ||
| r += copy_unmanaged_etc(sepolicy, src, dest, path)?; | ||
| } else { | ||
| dest.remove_file_optional(&path)?; |
There was a problem hiding this comment.
Or, like Ignition should we default to failing when there is an extant file there? That gets annoying though because suddenly one needs an extra override flag for when it's truly necessary.
|
That said...hmm. Maybe even without a registry, we should really still track this filesystem state in a somewhat more rigorous way by keeping each individual provided path as an extra hidden layer (ostree commit/ref), something like And now that we effectively have 3 sources for
We can diff all three of these. How exactly we make this visible gets tricky...and does still beg the question of supporting more useful metadata for them, and remote fetches. |
|
One technical difference here I am seeing vs systemd confext is that we definitely need to support configuring systemd units via this mechanism. |
cgwalters
force-pushed
the
install-inject-etc
branch
from
5e9e335
to
9da08da
Compare
|
FWIW, I rebased this and cleaned it up a bit. I'm still not totally sure about it though. |
This allows injection of arbitrary config files from an external source into the target root. This is pretty low tech...I'd really like to also support structured, cleanly "day 2" updatable configmaps, etc. But there is simply no getting away from the generally wanting the ability to inject arbitrary machine-local external state today. It's the lowest common denominitator that applies across many use cases. We're agnostic to *how* the data is provided; that could be fetched from cloud instance metadata, the hypervisor, a USB stick, config state provided for bootc-image-builder, etc. Just one technical implementation point, we do handle SELinux labeling here in a consistent way at least. Signed-off-by: Colin Walters <[email protected]>
cgwalters
force-pushed
the
install-inject-etc
branch
from
9da08da
to
d218625
Compare
This allows injection of arbitrary config files from an external source into the target root.
This is pretty low tech...I'd really like to also support structured, cleanly "day 2" updatable configmaps, etc.
But there is simply no getting away from the generally wanting the ability to inject arbitrary machine-local external state today. It's the lowest common denominator that applies across many use cases.
We're agnostic to how the data is provided; that could be fetched from cloud instance metadata, the hypervisor, a USB stick, config state provided for bootc-image-builder, etc.
Just one technical implementation point, we do handle SELinux labeling here in a consistent way at least.
Closes: #531